El análisis de requisitos es una actividad fundamental de la ingeniería de requisitos y podemos definirlo cómo el proceso de estudiar y refinar los requisitos de un sistema, el hardware o el software, por tanto sus objetivos son:
Estudiar las necesidades del usuario.
Refinar progresivamente los requisitos encontrados.
Modelar el entorno de la aplicación. un modelo de contexto ayuda a comprender cómo el sistema desarrollado encaja en su entorno.
Crear prototipos. Ayudan a que los desarrolladores y los usuarios alcancen acuerdos y garantizan la exactitud de la especificación.
Analizar la viabilidad de los requisitos.El analista negociará con el equipo de desarrollo para evaluar en qué medida es factible la implantación de cada requisito.
Priorizar los requisitos. Ayuda a identificar los requisitos más valiosos para los objetivos de negocio y a su vez facilita la planificación de releases concretas.
Aumenta el ROI (Return Of Investment, en español, retorno de la inversión).
Crear un diccionario de datos. El diccionario de datos contiene definiciones de los datos y las estructuras de datos que manejará el producto. De esta manera todos los participantes pueden ponerse de acuerdo en el tipo de información que recibirá, procesará y almacenará el sistema.
Modelar los requisitos. Consiste en realizar representaciones gráficas de los requisitos (Diagramas de flujo, entidad-relación, estado...). Estos ayudan a descubrir requisitos incorrectos, funcionalidades no contempladas...
Analizar las interfaces entre el sistema y su contexto. Consisten en analizar la relación entre la interface de usuario y otros sistemas.
Asignar recursos a subsistemas. Preparar la arquitectura del sistema, asignando funcionalidades especificas a subsistemas concretos.
Un diccionario de datos es una colección de información detallada sobre las entidades de datos que utiliza una aplicación y se utiliza para estandarizar la definición de los datos y permitir una interpretación común durante su análisis.
Los elementos de un diccionario de datos pueden pertenecer a una de estas dos categorías:
Primitivas: Son aquellos elementos de datos cuya descomposición no es posible. (Int, double, boolean)
Estructuras: Es la agregación de primitivas o estructuras.
Sus componentes se muestran en la columna «composición o tipo», donde se separan los diferentes elementos con un signo «+», indicando su agregación.
Cada elemento que aparece en esta columna debe tener su correspondiente definición en el diccionario de datos.
Componentes opcionales: Son elementos que no necesariamente deben ser proporcionados por el usuario o por el sistema (son opcionales).
Los componentes opcionales dentro de una estructura se indican entre paréntesis.
Grupos: Cuando un elemento puede contener a su vez varias instancias de otro elemento de datos.
Se indica encerrándolo entre llaves, mostrando el número de elementos permitidos delante de las llaves con el convenio «mínimo:máximo».
Ejemplo:
| Pedido | Petición de un nuevo producto químico del almacén o de un preveedor. | ID del pedido + Solicitante + Fecha de petición +1:10{Químico solicitado} |
||
| Lugar de envío | El lugar donde se deben entregar los productos químicos solicitados. | Edificio + Número de laboratorio + Sección del laboratorio |
||
| Número de contenedores | Número de contenedores de un producto químico que indica el tamaño del pedido. | Entero positivo | ||
| Cantidad | Cantidad de productos químicos en el contendor solicitado. | Entero positivo | ||
| Unidades de cantidad | Las unidades asociadas con la cantidad de un producto químico solicitado. | Caracteres alfabéticos | Gramos, kilogramos, miligramos. |
|
| ID del pedido | Identificador único de un pedido. | Entero positivo | Número secuencial entero generado por el sistema con cada pedido, comenzando con el 1. | |
| Químico solicitado | Descripción del producto químico solicitado. | ID del producto + Número de contendores + Cantidad + Unidades de cantidad + (Proveedor) |
||
| Solicitante | Información sobre el individuo que realiza un pedido. | Nombre del solicitante + Número de empleado + Departamento + Lugar de envío |
||
| Nombre del solicitante | Nombre del individuo que envía la petición de un nuevo pedido. | Caracteres alfabéticos | Puede contener espacios en blanco, tildes, guiones, puntos y apóstrofes. |
Las matrices CRUD nos sirven para analizar los datos y poder descubrir omisiones, errores e inconsistencias, relacionando los casos de uso con los elementos de datos.
Su acrónimo viene de:
Create (crear)
Read (leer)
Update (actualizar)
Delete (borrar)
| UC-003 Realizar un pedido | ||||
| UC-024 Modificar un pedido | ||||
| UC-098 Gestionar el inventario | ||||
| UC-065 Editar solicitantes | ||||
Cuando las expectativas del usuario son elevadas, pero el tiempo y los recursos limitados, es necesario asegurar que las funcionalidades más valiosas se implementan.
La priorización de requisitos permite asignar de manera eficiente los recursos, asegurando que las funcionalidades más interesantes estarán disponibles en el plazo de tiempo más corto posible.
Ayudan en la planificación de las iteraciones y son especialmente importantes en metodologías ágiles.
Como es muy difícil que todos los stakeholders se pongan de acuerdo en que requisitos son más prioritarios, hay que utilizar técnicas de priorización.
Para priorizar adecuadamente los requisitos es necesario tratar seis tipos de problemas:
Las necesidades de clientes y usuarios.
La importancia relativa de los requisitos para clientes y usuarios.
El momento en el tiempo en que es necesario entregar las funcionalidades.
Las dependencias entre requisitos, puesto que algunos de ellos son necesarios para poder implementar otros.
Los grupos de requisitos, que indican funcionalidades que solo tienen sentido en conjunto.
El coste de satisfacer cada requisito.
Se proporciona una lista de requisitos a los participantes y se les pide que tomen una decisión binaria para cada uno de ellos: ¿está dentro, o está fuera?.
Esta técnica es apropiada para utilizarla durante un workshop, y cuando la cantidad de requisitos es muy grande, porque permite un filtrado inicial.
Se agrupan los requisitos en tres categorías de prioridad: alta, media, baja.
Lo importante es que los stakeholders se pongan de acuerdo en qué significa cada nivel según su criterio.
Una manera de abordar el problema es considerando inicialmente dos factores o dimensiones de cada requisito:
Importancia: Indica qué valor aporta y cómo contribuye con los objetivos.
Urgencia: Refleja la prisa por obtener la funcionalidad.
De esto surgen cuatro combinaciones posibles:

Requisitos de prioridad alta. Son importantes y urgentes. Los usuarios los perciben como algo fundamental.
Requisitos de prioridad media. Son aquellos que son importantes, pero no demasiado urgentes, y pueden esperar a otra iteración.
Requisitos de baja prioridad. Son aquellos que no son importantes ni tampoco urgentes.
Los requisitos en el cuarto cuadrante pueden suponer un problema. El hecho de que algún usuario esté ansioso por obtener una funcionalidad poco relevante para sus propios objetivos o los de la organización, hace que tal vez haya que reconsiderarlos.
Este enfoque permite un refinamiento adicional de la priorización, de manera que se pueda desarrollar de manera iterativa.
Se trata de dar mayor prioridad a aquellos requisitos más valiosos para la organización o sus usuarios, empleando términos económicos.
Es una técnica de puja que se ejecuta durante un workshop:
Cada participante recibe 100 dólares.
Cada uno de ellos distribuye su dinero entre los requisitos presentados (puja).
Una vez finalizado se suman las cantidades de cada requisito y se obtiene la priorización global.
Esta técnica presenta algunos problemas:
Trolleo: Si un usuario desea realmente alguna de las características, puede utilizar todo su dinero (los 100 dólares) para «comprarla». De esta manera se introduce una desviación en el proceso, puesto que siendo objetivos nadie estaría dispuesto a desarrollar un producto con una única característica, y puede dejar fuera requisitos que son más valiosos para un conjunto de usuarios.
No tiene en cuenta otros factores como el esfuerzo de implementación. Muchas veces es mejor priorizar 3 características sencillas de 10 dólares cada una que una compleja de 15 dólares.
Mediante esta técnica se evalúa cada requisito en función de varias características:
Valor que un usuario percibe de un requisito teniendo en cuenta:
Beneficio que aporta la característica.
Penalización o prejuicio que se sufrirá si la característica no existe.
Coste de implementación de la característica.
Riesgo en la implementación de la característica.
Se obtiene matemáticamente una priorización global:
Además, a esta formula podemos aplicarle ponderaciones:
Ejemplo:
| Ponderaciones | |||||||
| Chequear adherencia neumáticos | |||||||
| Comprobar niveles de fluidos | |||||||
| Informar del estado eléctrico | |||||||
| Recopilar información histórica | |||||||
| Sumas | |||||||
Para aplicar el método se deben seguir los siguientes pasos:
Seleccionar los requisitos a priorizar.
Escribir la lista de requisitos en la primera columna de la tabla.
Estimar el valor total de cada requisito. (1-9)
Normalizar las valoraciones obtenidas: valor porcentual. V
Estimar el coste de implementación. (1-9)
Normalizar los costes obtenidos: valor porcentual. C
Estimar el riesgo técnico de implementación. (1-9)
Normalizar los riesgos obtenidos: valor porcentual. R
Calcular la prioridad de cada requisito.